Software Archaeology

some situation, trying to understand what you’re looking at and how it all fits together. To do this, you must be careful to preserve the artifacts you find and respect and understand the cultural forces that produced them. But we don’t have to wait a thousand years to try to comprehend unfathomable artifacts; code becomes legacy code just about as soon as it’s written, and suddenly we have exactly the same issues as the archaeologists: What are we looking at? How does it fit in with the rest of the world? And what were they thinking? It seems we’re always in the position of reading someone else’s code: either as part of a code review, or trying to customize a piece of open source software, or fixing a bug in code that we’ve inherited. This analogy is such a compelling and potentially useful one that Dave, Andy, Brian Marick, and Ward Cunningham held a workshop on Software Archaeology at OOPSLA 2001 (the annual ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications). The participants discussed common problems of trying to understand someone else’s code and shared helpful techniques and tips (see the “Tools and Techniques” sidebar).